In certain application fields, such as financial computing systems, very low latency data exchange channels are critical. Indeed, Radio Frequency (RF) networks provide lower latency compared to wired networks. However, the RF networks' reliability is subject to weather conditions, and signal reflection over water paths. As a result, they can quickly become unusable if no recover system is in place.
There exist different solutions to ensure that no packet is lost during a communication through data exchange channels. Such solutions comprise either standard solutions using a handshake type protocol or custom solutions using some sort of packet identification tags.
In particular, one existing solution is based on the Transmission Control Protocol (TCP). TCP is used for reliable communications where it is required to have a limited loss of packets or even, in some cases, no loss of packets at all. Such protocol is part of the Internet protocol suite and it provides a reliable, ordered and error-checked communication channel between applications over an IP network. The TCP keeps track of each packet and in case of packet loss or corruption, a retransmission is initiated. However, such TCP based solution is not suitable for very low latency data exchange as each retransmission add extra latency roughly equal to twice the latency of the communication channel. Moreover it cannot be used on a RF network whose reliability depends on weather conditions causing a lot of retransmission, thereby resulting in increased latency.
Another conventional solution is based on the use of a backup network along with a Frame Sequence Number (FSN). The backup reliable network can be used to recover lost or corrupted packets from, in order to reduce latency due to retransmission. A FSN is added to the packets and forwarded to both RF and Backup networks. This FSN is used to determine if packets have been lost on the RF network in order to be recovered from the backup network. The system queues the packets from the RF network until all lost packets have been recovered. This guarantees that the transmission order is kept. However, although such solution allows achieving lower latencies than TCP, keeping the sequence order often becomes very penalizing. Moreover, adding extra information to the packet going to the RF network results in an increase of the serialization delay (i.e. time to send the packet through the RF interface) hence the latency. Usually, such RF networks have a bandwidth of 100 Mbps which gives a serialization delay of 80 ns per Byte.
Further, using only a FSN to detect packet loss is risky if the RF network is very noisy. Indeed, if the number of consecutive frame lost is more than the maximum FSN then the recovery process can be completely out of synchronization. For example, if the FSN is coded on 8 bits, the maximum number of consecutive frame lost may be less than 256. Otherwise the FSN value might rollover so that it will not be possible to determine how many packets were lost.
Thus, improved systems, methods, and computer program products are needed for low latency packet recovery.